[#328] Improve royalty claim UX: post-claim state + claimed history#332
[#328] Improve royalty claim UX: post-claim state + claimed history#332realproject7 merged 2 commits intomainfrom
Conversation
- Post-claim: button disabled with "Claimed" text, balance reflects 0 - Success message shows claimed amount with clickable BaseScan tx link - Read cumulative claimed from getRoyaltyInfo; show "claimed so far" suffix when > 0 - Auto-reset to idle state on next data refetch after claim Fixes #328 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
T2b APPROVE
Single-file change, all acceptance criteria met:
- Post-claim: button disabled with "Claimed" text ✅
- Success message:
Claimed X WETH — tx: 0xabc...defwith clickable BaseScan link ✅ - Cumulative claimed: reads
claimedfromgetRoyaltyInfo, shown only when > 0 ✅ - Auto-reset:
queryFnresets txState to idle on next refetch cycle ✅ - "No royalties yet" message suppressed when
totalClaimed > 0✅
Minor style note (non-blocking): setting React state inside queryFn is unconventional — a useEffect watching txState would be more idiomatic. Works correctly as-is.
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
Verdict: REQUEST CHANGES
Summary
The UI changes are close, but the success state is cleared immediately by the manual refetch path, so the user does not reliably get the required disabled Claimed state and tx-link confirmation after a successful claim.
Findings
- [high] The component resets
txStatetoidleinside the query function, andexecuteClaim()immediately callsrefetch()after settingtxStatetodone.- File:
src/components/ClaimRoyalties.tsx:41 - Suggestion: Do not mutate component state inside
queryFn. Keep the success state visible after a successful claim, then reset on a later refetch cycle or in an explicit effect tied to fresh data. As written, the success state can disappear as soon as the manualrefetch()resolves, which undercuts the acceptance criteria for a disabledClaimedbutton and visible success message/tx link.
- File:
Decision
Request changes. The post-claim confirmation state needs to persist long enough for the user to actually see it before the component returns to idle.
Remove inline txState reset from queryFn and immediate refetch() call from executeClaim. Instead, use a ref+effect to detect the next automatic royaltyInfo refetch (30s interval) and reset to idle then. This preserves the "Claimed" success state with tx link until fresh data arrives. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
Verdict: APPROVE
Summary
The follow-up fixes the post-claim state regression by keeping the success state out of the query function and only resetting after a later data refresh. The UX now matches issue #328 closely.
Findings
- [low] The prior blocker is resolved:
txStateis no longer mutated insidequeryFn, and the component now waits for a later royalty-info refresh before returning fromdonetoidle.- File:
src/components/ClaimRoyalties.tsx:62 - Suggestion: None.
- File:
Decision
Approve. The component now preserves the disabled Claimed state and tx link after success, shows cumulative claimed amount when present, and local npm run build plus npm run typecheck both pass.
2 participants
Summary
Claimed X WETH — tx: 0xabc...defwith clickable BaseScan linkclaimedfromgetRoyaltyInfo(2nd return value); displays(claimed: X WETH so far)when > 0Single file change:
src/components/ClaimRoyalties.tsxFixes #328
Test plan
npm run buildpassesnpm run typecheckpasses